-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] TimeOut feature #14
base: master
Are you sure you want to change the base?
Conversation
…poses arrived for more than transformer_max_latency. To be compatible with (possibly lagging) simulation time, also added a `simulated_time` port.
Another point open for discussion is if stopping on timeout should be the default. |
I did not test yet how this behaves if the input transformation is generated from a slow and a fast task, e.g., a (slow) SLAM component which occasionally updates odometry2map, combined with a fast robot2odometry provider (we usually are ok with ignoring the slow odometry2map update rate). |
When we are watching the transformer timing out for a timeout feature, I think this is ok. As the max_latency parameter also defines how long the transformer waits until there is an error. so it has to be set to a high value to also get the slow transform. But this leads me to think about other component behavior, when you have a component that integrates the slow and fast transform, this one also has to stop sending transform, and this moves the high/low frequency issue around in the stack. So the fastest reaction time will always be the max_latency in the whole chain. |
Previously the trajectory follower was sending the last (old) motion commands whenever the poses were not updating. If I understand correctly, this has been fixed and now, when the poses don't get updated, this is what happens:
|
Why introducing in this same merge request the simulation time? Seems like a different feature. Maybe better to test one thing at a time? Or do you have tests ready also for this simulation time feature @chhtz? |
I see that there is also another change. Now in the error state the trajectory follower sends stop commands. Not sure if this is really what the component should do. Depending on the application, stopping the motion (maybe suddenly) can be bad. Addressing the next motion command once the trajectory follower has gone into error is maybe a task for a failure management component and not for the failed component itself. |
Added new state
NO_POSITION_UPDATES
and flag to stop when no input poses arrived for more than transformer_max_latency.To be compatible with (possibly lagging) simulation time, also added a
simulated_time
port.This can be slightly cleaned up, e.g., on timeout the whole trajectory follower logic does not need to be executed.
Also, maybe transformer_max_latency should not be re-used for this feature.